Exchange 2010 : Managing Exchange Recipients (part 3)

4. Managing Resources

Exchange 2010 resource mailboxes will be familiar to any administrator that has spent time with a previous version of Exchange. Exchange 2010 has some improvements that will make the Exchange administrator's job a little easier. In Exchange 2007 an administrator had to use the EMS to create and manage a resource mailbox. This left some administrators asking for another way to manage these mailboxes. One of the changes in Exchange 2010 now allows a majority of the resource mailbox settings to be managed using the EMC. You can use four tabs in the EMC to configure resources: Resource Policy, Resource Information, Resource Out-of-Policy Request, and Resource In-Policy Requests. The Resource General tab is shown in Figure 16-7.

Notice the Resource Capacity field in Figure 5. A resource can have a capacity defined in this field to denote the capacity of the resource. For example, you could list the number of chairs available in a conference room. If a conference room has room for five people and this is specified in this field, this information will be displayed within Outlook; however, this field is not used in determining a suitable conference room based on the number of attendees. This information is also not used by Exchange to determine if a meeting request is acceptable. There is also a space to add custom properties to better describe the resource. For example, you may want to identify conference rooms that have a projector, whiteboard, video conferencing equipment, or other features. By default, no custom properties are defined—you must define the custom resource properties for your Exchange organization. For more information on creating customer resource properties, see the help topic "Create or Remove Customer Resource Properties" at http://technet.microsoft.com/en-us/library/bb124948.aspx.

Exchange Server 2010 provides several options for configuring resource mailbox settings. Automating calendar processing has three options:

• Automated processing can be disabled (using the Set-CalendarProcessing cmdlet with the- AutomateProcessing None option).

• Resource booking attendant can be enabled (using the Set-CalendarProcessing cmdlet with the - AutomateProcessing AutoAccept option).

• Calendar Attendant can be enabled (using the Set-CalendarProcessing cmdlet with the –AutomateProcessing AutoUpdate option).

By default, the Calendar Attendant is enabled on each resource mailbox. For the resource mailbox to process and accept meeting requests, you must enable the Booking Attendant. In Exchange Server 2010, both the EMC and the EMS can be used to configure resource mailboxes.

Most companies have three common scheduling scenarios: automatic booking, manual approval by delegates, and manual approval from the resources.

• To enable automatic booking, the resource booking attendant should be enabled and the policy should be configured.

• To enable manual approval by delegates, the resource booking attendant should be enabled and then All Book In Policy should be disabled. The All Request In Policy should also be enabled and the delegates should be specified.

• To enable manual approval from the mailbox, the resource booking attendant should be left disabled.

The Set-CalendarProcessing command in the EMS has a number of settings that will help you to fully customize the behavior of the resource mailbox. Table 3 summarizes the settings that can be configured.

When defining the resource booking policy, you must consider who should be able to schedule a resource and whether all users should be able to book a resource for a meeting. The default settings may work for most resources in the organization, but consider restricting who can book important resources.

You might want to use resources in a number of ways. For example, if you have a large conference room you may want to restrict who can book meetings in it. You may also want to consider what times the resource can be scheduled and thus you may want to set restrictions on the time of day when meetings can be booked. To allow more people to use the resource you may want to restrict the length of meetings. Finally you should also consider the automatic acceptance policy for the meeting resource.

Equipment mailboxes and room mailboxes have similar features and are basically handled the same way. The main difference between the two is that a room mailbox is location-specific, such as a conference room training room or even an auditorium. An equipment mailbox is non-location specific and is used to provide a simple and effective way of managing resources for your users. Some examples of equipment mailboxes are shared portable computers, projectors, or even company vehicles.

One of the challenges in resource mailboxes and user calendars is that inconsistencies can occur because of improperly booked and cancelled meetings, user error, or software error. This can cause users to either miss a meeting announcement or have unreliable or outdated meeting information. Exchange 2010 utilizes Calendar Repair Assistant (CRA) to address this issue. CRA is a mailbox assistant that runs within the Microsoft Exchange Mailbox Assistance service on any Exchange server with the Mailbox server role installed. CRA will automatically detect and correct any inconsistencies that occur in single and reoccurring meeting items. CRA also detects and corrects the following issues:

• Attendee's calendar item has wrong time.

• Attendee's calendar item has wrong location.

• Attendee's calendar item is missing.

• Attendee's calendar item tracking status does not match the organizers tracking status.

• Attendee isn't on the organizers attendee list.

• Attendees and the organizer's reoccurring meetings do not match.

• Organizer and attendees have multiple calendar items that appear the same.

• Organizer's calendar items are missing.

By default CRA is enabled on all mailboxes. At times an administrator might disable CRA with the purpose of pinpointing the cause of recurring issues repaired by CRA. The EMC cannot be used to disable CRA. To disable CRA, run Set-Mailbox -Identity [email protected] -CalendarRepairDisabled:$true.

5. Moving Mailboxes

Even with the best intentions, you will most likely need to move mailboxes on a regular basis. Some of the more common reasons for moving mailboxes are:

• Corrupted mailboxes If you encounter corrupted mailboxes, you can move the mailboxes to a different server or database to fix the corruption. Often, moving a corrupted mailbox to another database will salvage any of the uncorrupted data in the mailbox.

• Load Balancing Because of the dynamic nature of many companies, users change positions or seasonal workers are hired for a short period of time, leaving mailbox databases with uneven numbers of active mailboxes. You may move mailboxes to even out the number of mailboxes in each database.

• Migration When you migrate from an existing Exchange Server 2007 or Exchange Server 2003 organization to Exchange Server 2010, you need to move mailboxes from the existing Exchange servers to an Exchange Server 2010 Mailbox server.

• Physical location changes You can move mailboxes to a server that is in a different Active Directory site. For example, if a user moves to a different physical location, you can move that user's mailbox to a server that is in a site closer to the new location.

• Outsourcing e-mail administration A company may want to outsource the administration of e-mail and retain the administration of Windows user accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario, in which the Microsoft Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.

• Policy Adjustments In cases where the mailbox databases are used to set the deleted item retention and mailbox limits, you may move mailboxes between databases to move a mailbox to a database with different settings.

• Reducing Database size In cases where data has been removed from a database and a lot of white space remains, rather than performing an offline defragmentation on the database, you can move the contained mailboxes online to a new database and delete the original database.

• Troubleshooting an issue If you need to investigate an issue with a mailbox, you can move that mailbox to a different server or different mailbox database. In some cases moving a mailbox that is having issues will help to determine whether the problem is with the server, the mailbox, or the mailbox database.

A local move is where a mailbox is moved from one database to another database within the same Exchange organization. At times you many need to move a mailbox to investigate an issue with that mailbox. If you encounter corrupted mailboxes you could move those mailboxes to another server because the corrupted messages will not be moved. In addition, you might want to perform a local mailbox move for load balancing and physical server location changes.

A remote move of a mailbox may be necessary if you are migrating to or from an outsourced Exchange deployment. In previous versions of Exchange, a mailbox wizard would run the mailbox move from the management tool. In Exchange 2010, the management tool is used to create a new move request. The new move request process resembles the move mailbox process in Exchange 2007, as shown in Figure 6. However, Exchange 2010 processes the request a bit differently.

A mailbox move is asynchronous in Exchange 2010, meaning that users are still able to access their mailboxes while they are being moved. After finishing the Move Mailbox Wizard, Exchange will only schedule the move by submitting a mailbox move request. This is the one major difference from Exchange 2007, where the wizard would not complete until the mailbox had been moved. With Exchange 2010, mailbox moves are run by the Mailbox Replication Service (MRS) in the background rather than within the Exchange management tools. The new model—in which mailbox moves are controlled by the MRS running on Client Access servers—has a number of advantages:

• Mailboxes are kept online during the asynchronous moves. The larger mailboxes become the longer it takes to move them around. Having online mailbox moves enables support of larger mailboxes.

• Moving the mailboxes is asynchronous, and the MRS performs the move.

  Figure 6. Move Mailbox Wizard

  

• The mailbox's dumpster now moves with the mailbox when you move it between Exchange Server 2010 Mailbox servers.

• Fast search is available upon completion. As soon as the mailbox begins to move, content indexing starts to scan the mailbox so that fast searching is available upon the move's completion.

• Each MRS instance, each mailbox database, or each mailbox server can be throttled.

• Mailbox moves now work over the Internet, and you can manage them from anywhere within the organization.

• A mailbox's move history is preserved.

To find out the status of a move request, run the Get-MoveRequest cmdlet using the EMS. For example, to move Matt's mailbox to DB100 using the EMS you would run New-MoveRequest –identity Matt –TargetDatabase DB100. After the mailbox move is initialized, you can check the status by running Get-MoveRequest UserName. The request can have one of the following statuses:

• Completing

• Queued for move

• Move in progress

• Ready to complete

Even with the benefits available in the initial release of Exchange 2010, additional improvements to the process were made in Exchange 2010 SP1. Some of the more notable improvements to the move mailbox process are:

• Outlook no longer needs to be restarted after a local mailbox move.

• A mailbox can be moved to and from a linked mailbox.

• The mailbox archive can be moved separately from the mailbox.

• The mailbox archive can be moved to an online hosted service.

• MRS can now import and export e-mail with PST files without the need to install Outlook on the Exchange server.

• A mailbox can now be moved to a new UM dial plan.